Complex software like applicant's SAP R/3 Release 4.5 (SAP) requires customization, e.g. selection of predefined functionality, and adaptation, e.g. addition of or amendment to functionality, as well as other servicing like program and data updates, cf. “SAP System Landscape Optimization” by A. Schneider-Neureither (Ed.), SAP Press, 2004, ISBN 1-59229-026-4, and “SAP R/3 Änderungs-und Transportmanagement” by Metzger and Röhrs, Galileo Press GmbH, Bonn, Germany, 4th reprint 2004, ISBN 3-934358-42-X.
Before such servicing may be performed, however, it has to be assured that the customizations, adaptations, program and data updates etc. are free of errors and integrate flawlessly into the software and data environment. In a factory for instance servicing errors are bound to result in costly workflow disruptions due to software malfunction or data corruption.
Such complex software may therefore be implemented in form of separate logical systems that together form a system landscape. A typical implementation of the aforementioned SAP software for instance may, cf. FIG. 1, comprise a development system 101 for customizing and development work, a quality assurance system 102 for testing functionality using representative test data, a training system 103 for training new users, and several productive systems 104, e.g. each for a different factory, for actual productive use. Other or additional users and systems may be defined according to the particular requirements.
The logical systems are identical in large parts, function autonomously and may be executed on a single computer. The quality assurance system 102 for example resembles the productive system 104 in that it provides all the functionality, its present data and additionally special test data. New customization settings or adaptations may thus be thoroughly tested in the quality assurance system 102 without jeopardizing the productive system 104. Likewise, the training system 103 resembles the productive system 104 in that it provides some of the functionality and special test data. A new user using the training system 103 may thus become accustomed to the functionality and observe the effect of his actions, albeit without disturbing the productive system 104.
A transport management system connects the logical systems and serves to forward approved services to the next stage of the system landscape via logical transport paths 105. A service may for example be approved in the development system 101 for export. It will then be forwarded to an input buffer of the quality assurance system 102. Import into the quality assurance system 102 is approved manually by an operator. Once the service has been imported into the quality assurance system 102, it will automatically be forwarded to an import buffer of the training system 103 and the productive systems 104 where it will be imported following manual approval by an operator.
Additionally, the operator may also effect a software service directly by manually performing customizations, adaptations, program and data updates etc. in a system. Such direct software servicing does not require a formal software service to be sent through the systems in the system landscape.
For the sake of system stability, in particular with respect to the productive system, it is desirable to restrict the changeability of one or more systems not only on a user or operator basis, but also on a system basis so that a user or operator who principally has sufficient authorization to approve an import or effect a change may be prohibited from doing so in a particular system. It is known to define the changeability on a system basis by change options that are kept within each system. If the change options of a system need to be altered, a sufficiently authorized operator has to log in into the system and alter the change options manually. This is time consuming, in particular when different systems are affected by different projects, and bears the risk of errors.